home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
IRIX Base Documentation 1998 November
/
IRIX 6.5.2 Base Documentation November 1998.img
/
usr
/
share
/
catman
/
u_man
/
cat1
/
ftimer.z
/
ftimer
Wrap
Text File
|
1998-10-20
|
2KB
|
67 lines
FFFFTTTTIIIIMMMMEEEERRRR((((1111)))) FFFFTTTTIIIIMMMMEEEERRRR((((1111))))
NNNNAAAAMMMMEEEE
ftimer - report realtime itimer status
SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS
ffffttttiiiimmmmeeeerrrr
DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
_f_t_i_m_e_r provides the cpu number of the processor handling the fast clock
used by the real time itimer facility. It also reports any outstanding
real time itimer timeouts.
The fast clock is inactive until it is first used, then remains active
from that time onward. The fast clock typically becomes active when a
realtime process (i.e., those running with a non-degrading priority, see
_n_p_r_i(1)) executes _s_e_t_i_t_i_m_e_r(2), or less frequently when some special
kernel driver needs the fast clock enabled for a high resolution interval
timer and executes an internal kernel routine.
A user can control which processor handles the fast clock interrupts by
using the _m_p_a_d_m_i_n(1) command or the _s_y_s_m_p(2) programmatic syscall.
Note, however, that _f_t_i_m_e_r(1) has no real relevance for Challenge/Onyx
platforms, as "fast clock" interrupts are handled by all processors, not
just by a single processor. For Challenge/Onyx the distinction between
"fast clock" itimers and "normal" itimers is made on the basis of what
time resolution is available, not on the basis of which physical hardware
clock ("fast" or "normal") implements the itimer. As with the other
platforms, realtime processes can get access to high resolution itimers,
and non-realtime processes can only use "normal" resolution itimers (see
_s_e_t_i_t_i_m_e_r(2) and _t_i_m_e_r_s(5)).
SSSSEEEEEEEE AAAALLLLSSSSOOOO
npri(1), getitimer(2), setitimer(2), realtime(5), timers(5), mpadmin(1).
PPPPaaaaggggeeee 1111